as per CONTRIBUTING.md states, I hereby pinging one of you. ( @kinggoesgaming )

Also suggesting checking on my other PR #753

I think the name rfc on its own isn't specific enough to tell what it should be so we could make it rfc9562 instead. The old RFC got almost 20 years of mileage out of it so I don't think we're at a big risk of needing to do this a second time anytime soon.

I agree, sort of. name rfc is kinda meaningless unless somebody is familiar with it. However, the name rfc9562 is kinda the same, just feels like code smell to me. Perhaps a name like gregorian would make sense. (as the RFC in fact call it that way multiple times)

I'm not fully convinced we should do this. [...] just a nuisance as a user. I think it's something to keep up our sleeves though if we find a better API in the future to push users to.

No disagree here, this PR indeed is some bikeshedding. More like an attempt to push the crate in the direction for some cleanup efforts.. as it is a little bit lorn... yet, it is very much on the important side of all crates. (top 100)

I do have some new ideas for a new API, would mean a major release. I will share it on the relevant PR soon (when the PoC is working as expected)

so, back to this PR. What do you think about a rename to from_gregorian_timestamp()/gregorian_to_unix()/etc?
If you are up for it, I adjust the PR... if not, just close it. no hard feelings :)

I think we can revisit this after I finish #755, it ends up needing to add to the timestamp API to support the more sophisticated counter requirements in v7 UUIDs.

#755 is merged now. I think if we rename these, we could possibly use the name gregorian_timestamp rather than rfc_timestamp to distinguish the 100ns ticks since October 15, 1582, and the 1ns ticks since Janurary 1, 1970.

I don't think this needs to block our next release, because it doesn't add any new methods we'd want to deprecate.

Renamed the rfcs to gregorian.

Also I attempted to rename the Variant field, with backward compatibility. It adds a slight plus complexity, but will disappear when we delete deprecated items.

It may not be fully super BC... but I guess for that User has to do some very niche edge case what they probably should not do any ways.

https://github.com/uuid-rs/uuid/pull/754/files#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R350

Anyways, feel free to cherry pick... or just close if it's not needed. (deprecation warnings points to future version 1.9.1)

Thanks @Mikopet. I think the name Variant::RFC suffers from the same issues as rfc in function names but I think we should be ok to leave Variant as-is. It's already pretty niche. We'll deprecate the function names in the next minor release. Would you be happy to change those to point to 1.10.0?

I think the name Variant::RFC suffers from the same issues as rfc in function names

Indeed, but not that much. My reasoning is: while the RFC mentions "Gregorian" many times (so they call it by name), the variant field just says: The variant specified in this document.

should be ok to leave Variant as-is. It's already pretty niche.

I agree on that, it is indeed very niche. This is more likely a thought experiment and an attempt to put this things in order in a compatible way.

To be honest, I don't really like the current Variant/Version enums. They are not representating the things written in the RFC very well. I would suggest a more nearby approach to it.

I don't have ready implementation for it, but some idea I do have. I'm happy to jump on it, if you think it could be a good direction:

• Having one enum for both, something like Field/Parameter or similar.
• This enum would have two fields, exhaustive: Version(u4), Variant(u4)
• When we do override, instead of .with_version()/.with_variant() we simply use .with(Parameter)
• .set_*() same. perhaps the name of that function also could change to terminology in the RFC.
• I'm unsure about the .get_*(), but perhaps it could return with a tuple

Anyhow, I updated the commits!

Thanks for working on this @Mikopet! I've cherry-picked your first commit into #765, which I plan to release as 1.10.0.